We'll be right back.
We'll be right back.
We'll be right back.
We'll be right back.
Once you have that path independently encrypt and independently authenticate with your final endpoint, and finally, once you have that link set up, forward services over that end-to-end setup.
Now, one of the big things that I've done when I've been working on SSH is making it actually usable to do all these things.
Very pragmatic law.
If it isn't usable, nobody uses it.
Now, I'm spending some extra time talking about this because a lot of people here who've...
who've ever worked in corporate America have seen really nice, really expensive systems that are a complete useless thing because nobody can figure out how to get them to do anything.
And everyone just makes little nice hacks around it, cheats around the system, and management accepts it because at the end of the day, the connections actually work.
And business does not exist for security.
Business exists to actually make money.
Basics.
Bringing people up to speed.
Don't worry.
This is not another talk about...
Ooh, we're going to talk about how to make a link simple local port forward today.
We're going to go a little bit beyond that.
But for those of the audience who don't fully know about OpenSSH, we're going to start a little from scratch.
First, SSH exists to go ahead and forward shells.
Just like Telnet, you go in, you go to the host.
SSH actually does it a bit better.
It clears up a lot of the old issues with regards to spacing, with end curses.
It clears most of that up.
It also does X if you're actually still using X, which...
Anyway.
No, basically, you SSH into a host, X magically works if you have X forwarding set up correctly.
Now, the reason X is not set up by default anymore is because there's a pretty nasty security hole.
In the X protocol, every character that's sent and everything that's on your screen is actually accessible by the other side.
So if you connect it to a rooted server, that server will be able to see not just the text that you sent,
it would be able to see everything on your screen and every character that you entered.
So, automatic X support was disabled in modern versions of OpenSSH.
Also, OpenSSH allows you to execute single commands on remote hosts and have those appear as if it's local.
And finally, OpenSSH forwards single ports at a time.
The bullshit geek definition of all this is, quote,
all SSH forwards are non-exclusive and non-transparent figments of user space.
Ignore that.
SSH under Windows.
I know a lot of people don't particularly like Microsoft, but the reality is, cross-platform,
the ability to use the same solution on every platform, including Win32, is pretty nice.
So there is a package named SigWin.
That is a Unix prompt on a Windows machine.
It is moderately evil, but it is nice.
Uname works, VI works, yes, you can actually control Z out of your commands and it'll work
pretty much, if you're familiar with Unix, you can finally have a useful Unix desktop.
The reason I use it primarily is...
I get an actual SSH client, I don't have to deal with secure CRT, I don't have to deal
with 80,000 Windows popping up, I actually get a genuine system.
You got it.
This better?
Thank you for telling me.
If anything else idiotic happens, please notify me.
Forwarding shells.
Syntax.
Very simple.
SSH.
User-friendly.
User at host.
Encryptions.
Triple-desk.
Blowfish.
AES.
Authentication is your standard, either RSA or DSA, or it uses passwords.
Key generation is pretty trivial, either for SSH1, do SSH keygen, for SSH2, SSH-keygen-DSA.
Don't worry, you don't need to try to write all this down.
The slides will be made available on www.docspara.com.
But basically, this is how you set up a key so that you can log into a remote machine,
and this is how you send that key to the other side.
That's what I have set up on this slide.
Forwarding commands.
SSH user at host.
Simply CLS.
Simply append at the end of your string the command that you wish to run.
SSH is fully 8-bit clean, which basically means that you really can run arbitrary commands,
and they will fully proxy successfully.
Now this is going to be used later so that we can go into a host and set up links through
it using the 8-bit clean functionality, so this is actually extraordinarily useful.
CD burning.
Starting over SSH.
I apologize, I actually can't demonstrate this, but the general idea is the standard
command to burn a CD is simply make ISO file system, throw on the Joliet index of names,
throw on the Rockridge index of names, pipe that over to the app CD record, tell CD record
how fast you want it to burn, tell CD record the SCSI ID of your machine, and simply tell
it, now that you have this information, pick up the ISO image.
Off of standard in, of course, standard in is being fed by the make ISO file system
command.
To SSH enable that, all we do is just add in SSH user at host before CD record.
All we do is basically change, tell our operating system, instead of running a local CD record,
run it over there.
The convenient thing now is instead of having 30 machines with 30 burners in them, because
you have 30 people who need to use the same thing, there's one machine.
It has one burner.
And everyone simply sends their files over to it.
The encryption comes free.
The authentication comes free.
It's moderately convenient.
Plus the fact that everything works under SIGWIN and works over Windows means you can
have all your Windows desktops send files to the one Unix system with a burner.
And nicely enough, that machine won't crash like this did earlier.
File transfer without SCP.
I don't know how familiar people are with SCP or SFTP, but they're pretty much both
garbage.
They rarely work.
They get on your nerves.
Basically, by executing simple standard Unix commands, cat, ls, tar, tail, maybe even dd,
you can go ahead and you can actually implement pretty much everything that you'd want out
of FTP in the SSH framework.
I'm planning on implementing all of SFTP using nothing more than these commands.
The advantage being finally transferring files using SSH will, any host that you can SSH
into, you should eventually be able to transfer a file from.
No matter what.
No matter how much or how little is installed on it, the default software that's enabled
will be sufficient.
Typo?
Typo?
Typo?
Typo?
Typo?
Typo?
Typo?
Typo?
Typo?
Local forward, listen on local 8000 to what the other side sees as the local host port, port 80.
You can basically look at the syntax and separate it into listener versus location.
Whatever comes first is the listener.
It's where the listening port is.
It's where new connections come from.
If new connections come from my side, it's a local port forward.
If new connections happen on the other side, it's a remote port forward.
Limitations on port forwards.
By default, only systems directly hosting the listener can connect to it.
If I have a local listener on my machine and somebody on my same subnet wants to access it, by default, they can't.
That way, people can't use me as a bouncing off point to whatever host that I happen to be connected to.
For example, my mail server or whatnot.
You can make local forwards public by using the dash G option to SSH.
But remote ports have to be enabled using gateway ports on the server side.
So.
I can't go ahead and have my own.
So, okay.
I have a web server on my machine.
I want my web server accessible on some other machine.
I can make a remote port forward and I can say, make remote port 80 equal to my port 80.
But the only machine that's actually going to be able to access that web server forward is going to be the machine that I connected to.
Accessing port forwards.
There are a couple ways to handle this.
First of all.
You actually just tell your application, go straight to 127.0.0.1 or perhaps you go ahead and you go into your host file.
So, you basically preempt DNS.
This is pretty inconvenient and all hosts that you connect to have to share the same IP.
Then, it's flexible.
Works for mail, works for SMTP, works for POP3, works for IMAP.
Works if you're connecting to a single web server at a time.
You can go ahead and you can have a web server redirected to 127.0.0.1.
But it doesn't work too well when you have eight web servers that you want to connect to.
Or you just want to connect to the web in general.
You don't want to have to say in advance what machine you're trying to get to.
Furthermore, the port forward methodology completely fails for stuff like FTP.
Solution.
Dynamic forwarding.
This is an undocumented feature right now in OpenSSH 2.9.
Dash D1080.
It opens up a SOC server in the SSH client.
Now, even though the SSH client goes ahead and demands that you in advance say where you want it to go.
The protocol doesn't care.
The protocol says when a TCP session is established, the destination is set at that time.
If you have 10 TCP sessions, there are 10 opportunities for a destination to be established.
So, it'd be really nice since every single time it could be different if applications can go ahead and say,
yes, this one time I'm connecting to you, I'd like to be going to CNN.
This one time I'm connecting to you, I'd like to be going to PacketStorm.
This other time, and so on.
Well, SOX is pretty much the simplest possible protocol for doing this.
It's a few bytes at the beginning of a TCP session that basically go ahead and say,
this is where I actually wanted to go.
Now, I don't know how many people here have done SOX programming.
SOX programming is so, so ridiculously overcomplicated.
You use library preloads and link stuff in, and usually SOX goes ahead and reduces stability on the client side.
It's eight bytes, people.
If anyone here ever does a SOX client, please, just write the eight lines of code it takes to implement it.
Application support.
You get Internet Explorer.
You get FTP.
You get instant messengers.
You get P2P clients.
Napster worked on it when there still was a Napster.
Dialpad.
Yes, you actually do get some variant of voice over IP over SSH using dynamic forwarding.
It's a generic solution to a very wide problem, which is,
how do you dynamically set up, or how do you support protocols that have dynamic destinations
that go to multiple sites, and this is basically the solution.
False in the hack.
It is not a full VPN solution.
Your network is not isolated.
You're both on the network that you're directly connected to,
and you have this link into the foreign net.
I may be connected to...
Anyway, forget it.
The big problem is server freeze.
SSH is basically implemented with a gigantic select loop.
It is not multi-threaded in any shape, way, or form.
That's probably a good thing.
Makes the internal code very simple to understand, very simple to extend.
The problem is if any single operation inside of the SSH daemon blocks,
if any of it freezes waiting for an answer,
the entire server process just freezes.
Now, you can't go ahead and denial of service anyone else this way,
because SSH forks off other copies of itself.
But your own client dies, so if you have one TCP session that causes a freeze,
all your other channels, everything else freezes as well.
So it's not perfect.
OpenSSH is better in this regard.
It has less calls that end up going to...
It has less synchronous calls,
but the one nice thing is you actually do get some modicum of support
all the way back to SSH 1.2.27.
That's been a big goal with a lot of my engineering,
to actually try to go ahead, support the oldest servers in the book,
because let's be honest, the old servers are never getting upgraded.
We can't get them upgraded if there's a root compromise in them.
How are we going to get them upgraded so there can be new features for users?
So any extra features that I've been working on
have pretty much been on the client side.
Make the client do more, put more intelligence in the client,
because the person doing the upgrading wants a new feature.
They want a new feature.
They have a personal reason to go out and get it.
A sysadmin has no personal feature that they want.
Or if they do, they still have this whole process
of updating something on a production server
that's been out for four years, blah, blah, blah.
Annoying.
Bottom line, upgrading the client if you can
is usually a better strategy for actually making stuff work.
Proxy commands.
Proxy command is basically the method by which SSH did SOC support.
A proxy command is an arbitrary command
that after it's completed leads to the SSH server
in an 8-bit path.
So if you look there, we have a netcat to port 22
on some random SSH server.
The response is, well, here's your SSH banner.
SSH 1.99 open SSH 2.9 P1.
The idea is you could have some arbitrary tool
that does the SOC's negotiation,
does the whatever negotiation that you have to do,
and in the end gives you SSH 1.9 open SSH 2.9 P1.
This way open SSH doesn't need to care
what tool you're using to get to the final destination.
It doesn't need to hear about what protocol.
In the end, if it's got its 8-bit path,
it'll go through it.
Well, SSH wants an 8-bit path.
SSH provides 8-bit paths.
Can we go ahead and use SSH to proxy itself?
The answer is yes.
The correct method to implement to do this
is you have the remote side open a port forward
to an SSH daemon
and connect it on the client side
to standard in and standard out.
Now, that's the correct method to implement it.
I'm not that good of a programmer.
Believe me.
So I have a cheap hack.
I remotely execute Netcat.
So I remotely execute Netcat on a machine
that can actually get to the host that I'm trying to go to.
So I SSH into my bastion host,
my one box, my NAT machine.
I SSH into that.
And on there, I Netcat over to my desktop
or to my computer.
To my workstation or whatnot.
And I Netcat to its SSH daemon.
Using Netcat based wire mode,
SSH dash O, proxy command,
SSH user at proxy,
Netcat to the correct host,
the correct port,
and the username at the server,
or username at the workstation or whatnot.
This is a mess.
This is completely unusable.
I'm aware of this.
You're aware of this.
Everyone's aware of this.
So there's a rather simple,
much simpler syntax under development,
which is basically SSH dash B,
proxy, user at server.
So SSH dash B,
my one machine that's actually internet accessible,
and then some name of a machine behind there.
The encryption actually happens between me
on the outside world
and my machine inside my network.
It does not actually decrypt
at the host in the middle.
The host in the middle is only being used
to provide a network accessible path.
Now there's still authentication
to the host in the middle.
There's still encryption to the host in the middle.
So as an administrator,
I know that there's a guaranteed amount
of cryptography going on.
But as the administrator,
I lose the ability to go ahead and,
or I lose the risk of having this one machine
that has complete ability to decrypt all communications.
Little statistics for you.
I went into a very, very large bastion host
at a major company,
and it had 75, 100 people at SSH into it.
They were using it as their bouncing off point
to go to their workstations,
to go to their desktops or whatnot.
75 people had SSH into other desktops.
25 people had R logged into other desktops.
10 people had Telnet into other desktops.
So here you had one machine,
internet accessible,
with full decryption,
full authentication ability
to get into a hundred other computers.
Proxy authenticates,
proxy decrypts,
proxy internet accessible.
The moment this machine gets hacked,
and it will someday,
that entire network is screwed
with my solution,
that network is not screwed.
It was only used as a pathway.
It could not actually decrypt or authenticate
against any machine that it was used as
as a bouncing off point.
Now,
what if there's no internet accessible bastion proxy?
Now what?
What you can do with SSH
is you can set up what are known as remote port forwards.
I can,
we'll just walk through it.
My machine on the inside of a network
that is firewalled,
SSH is out into my machine at home.
Sets up a remote port forward,
says,
hey machine at home,
your port 2022,
if you get any communications,
listen,
send them to me,
and I will feed them to my local 127.0.0.1.22.
When the client wants to go ahead and connect,
it either uses that really hideous command
with host key alias,
or it just says,
SSH user at proxy use,
actually that's wrong.
SSH goes in,
that should actually say,
it goes into itself,
go into your own port 2022,
and connect against them,
ah,
forget it.
Bottom line,
okay,
damn you ghetto hackers,
damn you.
No, seriously,
the idea is basically
to use the keys as your addressing method.
Just go ahead and stop trusting,
ah,
damn it.
The idea is if you can't trust an IP address,
you know,
oh my god,
everyone can spoof this IP,
everyone can spoof this,
everyone can spoof that,
don't.
Connect to any IP you want.
If you can see that your cryptographic keys said
you connected to the right host,
you know whether or not
you're at your destination or not.
Forget the addresses,
connect to any IP,
allow remote port forwards,
allow anything to bounce wherever.
In the end,
you know whether or not
you're connected to the correct host,
because of the cryptography,
not because of the addressing.
It actually works.
Now,
you do actually need
to check your host key.
You do need to actually check
that the remote machine
is who they claim to be.
You really need to do this
when you're forwarding to local host,
because as Sage will say,
you know what,
this guy could have 80 connections
going through local host.
I'm not gonna automatically force
a check on host keys to local host.
So you either have to use
the host key alias
or use the new concentrated syntax
that I just have to say
that I had trouble explaining,
which sucked.
Two machines.
Both of them are firewalled.
Both of them are firewalled
against each other.
Usually the way this is resolved is,
goes up to management,
management fights back and forth.
You open a firewall.
No, you open a firewall.
No, you open a firewall.
And it just goes on and on and on,
and eventually somebody gives in
because they're losing too much money.
Whoever loses more money
has to go ahead
and insecure their network.
There's a better way.
But both machines go out.
Both machines go out to some machine
that they can both connect to.
One machine sends over its SSH port.
The other machine connects
to the sent over SSH port.
They meet in the middle.
They know they're actually
talking to each other,
again, because of the cryptography.
If it works, they talk.
If it doesn't work, they don't.
So you have some host in the middle.
It could be in the middle of a 7-Eleven.
It could be in the middle
of DEFCON,
and it wouldn't matter
because in the end,
the encryption is end-to-end.
This host in the middle
is only being used as a pathway
and nothing more.
Escape syntax.
Something that's not known
about too much.
SSH actually has a decent amount
of live configuration.
There's a decent amount
that you can do
while the SSH client is live.
Hit enter.
Hit tilde, question mark,
and you'll actually see that
out of your SSH
client.
And you can go ahead
and have it terminate
the connection and suspend
and list your forwarded connections.
A bunch of really useless things.
Sometime in the next few weeks,
you should be able to
pretty much modify any option
in the SSH.
Basically, anything that you could do
at the command line
when SSH started,
you'll be able to do
without having to go ahead,
disconnect and reconnect
and re-authenticate
and redo all of that stuff.
SU.
I kind of got a laugh out of this.
There's a guy outside
who has a car
and his license plate says SU root.
Really cool car,
really nice car,
really, really,
really insecure command.
SU is not secure
because you don't actually ever know
you're executing SU.
You go ahead,
you SSH into some remote host
and you connect as your username
and you see your shell prompt
and it's your user shell prompt
and you ask your shell prompt,
please load SU.
I want to go ahead
and be a different user.
I want to upgrade my permissions.
How do you know your shell's actually executing SU?
There's absolutely no reason
for you to believe that
and in fact,
a trivial attack against your bash RC,
a trivial attack against anything
will go ahead
and redirect that SU command elsewhere.
Maybe it'll redirect it to a Trojaned SU.
Maybe it'll just fail the first time
after it gets your password.
The bottom line is
you can't trust SU
after your shell has run.
Trojaning an administrator's personal account
and just waiting
for them to switch to root
is an absolutely deadly attack.
So the solution is
you have the SSH daemon execute SU for you.
Now when SSH executes commands remotely,
it does not load your bash RC.
It does not load anything
that's personally connected to you.
It checks your authentication credentials
and then loads the command, period.
Which means that
because SSHD is usually a root-owned file,
you go from local to remote,
remote root to,
and I'll call on you in a second,
remote root,
the root-owned process
never goes through user-level permissions.
It goes straight to the user
you really want it to be.
There's a new syntax being added,
SSH user plus root.
So the plus goes ahead and automates that.
Now somebody here thinks
that this is wrong
or incorrect or whatnot,
so I'll go ahead.
I actually had a question.
Does this mean that if you change,
a user's shell to bin false,
like for a pop-up main account,
they can still SSH in and execute commands?
I believe that actually executes commands
through the user's default shell.
So if the user's,
yes, actually I'm sure of that,
because that's how people implement SCP-only shells.
So it doesn't run the,
it runs specifically user shell dash C,
then the command that needs to be added.
So if it's bin false dash C command,
well, false isn't going to do anything.
So the user still doesn't have a shell.
Your shell, your personal shell
is restricted by administrators.
You have a file at C shells
in most Unix distributions.
It limits what you can select
as your own personal shell.
So the user can't even go ahead
and change shell out of
that box that you're making them.
There are problems with this.
The big problem is that
you have to use root passwords.
You have to have,
generally, a single root password.
You can't use the public key method.
You can use public keys to go ahead
and log in as your individual user name,
but everyone still has to have this root password.
This root password almost never changes.
So somebody leaves your company,
guess what?
They still know root on all your servers.
One solution to that is individual public keys.
You can have a large set of public keys
able to log into the same account.
If you have everybody who's individually authenticated
to use that root account,
actually use their own personal key,
when they leave,
you cut their key.
Are there problems with this?
Yes.
The primary problem being is
if people have root on a server ever,
if they really want to,
they can never have to leave.
It's called load a kernel module.
But it can be a useful technique.
PPTP over SSH.
This is evil.
But it is a good example
of how SSH's arbitrary functionality
is rather useful.
PPTP is implemented...
Let's see how we can do this.
Okay.
PPTP is a fugly protocol.
It is Layer 2 PPP inside of Layer 3 GRE,
which transmits Layer 4 TCP, UDP, and ICMP traffic.
It also uses a Layer 4 port,
1731 TCP.
I'm sure I could design a worse protocol.
Somehow.
I don't know.
It was created by Microsoft,
which we'll leave it at that.
The nice thing about it, though,
it is really, really well integrated into Windows.
It just works.
One of the more painful things, incidentally,
about any kind of VPN solution
is if Microsoft doesn't write it
and you install it,
it has a pretty good chance of blowing up your system.
Doing any kind of protocol shim
in Windows operating system,
it either works perfectly
or you might as well throw your laptop out.
It's one of the two.
I lost two laptops to the Nortel client,
so I'm allowed to say this.
So the problem with just going entirely
with the Microsoft solution
is the crypto isn't very good.
It's decent.
Version 2 is decent.
Version 1 was kindergarten crypto.
It was pretty much a good example
of every single screw-up that you could make.
You took the key stream going one way,
you X-sorted against the key stream going the other way,
and there were your keys.
Fuck.
PPTP version 1 was a mess.
But again, even it had decent network isolation.
So you can't trust PPTP's crypto.
It sucks.
But you can trust SSH's.
So could you go ahead and use
PPTP's network isolation
along with SSH's trustable crypto?
And the answer is you can.
Use Poptop.
Requires another machine at your site.
Real operating system.
Unix.
Sorry for being a little bit of a bigot there.
Basically, Poptop goes ahead,
implements the listening on 1731 TCP.
It implements the GRE encapsulation
and decapsulation.
But it does not reimplement the PPP protocol.
Instead, it just runs the Unix command that does PPP,
which is either PPP daemon,
which is a root linking process,
or Slurp,
which basically was NAT circa 1995.
Slurp was invented so that you could have,
just have a shell account.
You could run this command
and it would convert everything coming over the line
into, it would interpret PPP,
set up the necessary connections,
but not actually do it at a root level.
Not actually do it at a kernel level.
Just translate it all into standard system calls
that you could do as any user.
So either PPPd or Slurp
gets executed by Poptop,
who says it needs to be local.
You don't necessarily need to,
if you're running PPPd,
or you're running Slurp,
why do you need to run it on your own machine?
SSH into a remote machine
runs Slurp there.
So Poptop goes ahead,
listens for connections,
receives one,
says, ah, I now need to parse PPP.
Well, how do I do this?
I go to that machine on some far away land,
far away network,
and I run Slurp over there.
And suddenly, my machine on this network
is over SSH,
network isolated on some completely foreign network.
And if I use Slurp,
I don't even need to be root on that foreign network.
Go ahead.
Is the Poptop or PPPd
in general using
IP protocol rather than
sending the data through the TCP stream?
That's absolutely correct.
The TCP stream is only used for the control protocol.
The actual data is the PPP encapsulated GRE.
And how do you...
So, okay.
So Poptop's sitting on this helper server.
It takes the GRE packets
coming out of your Windows machine.
It strips the GRE,
sees PPP,
takes this PPP,
attaches it to a PPP daemon
on a remote server.
And so it's just sitting in the middle,
connecting things.
This is the really lazy way
to go ahead and set this up.
It's precompiled into Poptop to load Slurp.
You rename Slurp to Slurp binary
and just have the actual Slurp command
be a shell script to do a remote execution
of this command.
Now, the reason I actually went ahead
and showed you this is yes,
Poptop's open source.
You can go ahead and modify it.
Sometimes you have to deal with apps
that aren't open source.
Sometimes you have to deal with apps
that just go ahead and feel like
shelling out every once in a while.
Be aware every time you have an app
that shells out to a command,
you can wrap that command
with something that executes it remotely
and therefore add rudimentary network support
to pretty much anything.
One final thing I'll go over
then I'll open to questions.
Not talking about SSH for a moment.
SSH has some problems.
Just like SSL has problems.
Just like those great nice custom hardware solutions
you see for crypto have problems.
They're all link-based.
They all decrypt the information
as soon as it comes back off the wire.
They all decrypt the information
using a key that,
because it's a link-based crypto,
the key's online.
The key is a machine
that's connected to the network.
You have lots and lots of credit card numbers
out there that are picked up over SSL
and are dumped unencrypted into a database.
The encryption is stripped off
as soon as it hits this box in the DMZ
of some company's network.
Then they wonder why they get
300,000 credit card numbers stolen.
Well gee, you didn't encrypt them
and even if you did,
you had a key in the same place.
It's like I put a key in front of your door
and then I,
there's a key in front of your door
in the hotel room.
Someone goes ahead and says,
ah, here's the key.
Opens up.
But the door was locked.
The key was right there.
What the do you expect?
File-based systems can go ahead
and actually separate this out.
You go ahead.
This is called a lock-drop method.
You go ahead and you have lots and lots of machines
that can go ahead and encrypt data.
They have a public key.
Public keys let you encrypt.
They do not let you decrypt.
So you have all your machines
that go ahead,
that you want to go ahead
and do lots and lots of encryption.
Because really,
encryption's a more common operation
than decryption
in a lot of contexts.
You want to store
lots and lots of credit card numbers
for often for a long time.
To actually mass read them,
how many legitimate uses are there
for mass reading 300,000 credit cards?
Emphasis on legitimate.
So the idea is basically
all your machines
that are generating logs,
all your machines
that are receiving important data,
they file and encrypt it.
The decryption key
does not exist on those machines.
In fact, ideally,
the decryption key
does not exist on any network.
So if somebody breaks in,
they could completely root everything.
There's no way to get access
to the old data.
It's all encrypted
and the decryption key
is absolutely nowhere to be found.
Now you can only do this
with asymmetric systems.
You can only do this with systems
based off of something
that has a public and private key.
If you have something,
some pure triple desk
where there's, you know,
use this string of bits
to go ahead and encrypt.
Well, the same string of bits
used to encrypt,
someone just says,
great, here's the string of bits.
I use it to decrypt.
Public keys get you
around that problem.
And we're actually just
going to open up to questions.
The bottom line
that I have with SSH
is it's really powerful.
It's really flexible.
The bottom line with SSH
is that it exists
as a secure encapsulator
of a large amount
of functionality.
It's really powerful
in the traditional insecurity
that there's a constant tension
between functionality
and security.
The more functionality
you open up,
the less secure
you're supposed to be.
So it's somewhat confusing.
Why is SSH successful
in what it does?
The bottom line is
SSH is successful
because it implements
generic functionality
that you don't have
to make hacks on to add.
Best example,
SSL upload
over an HTTPS server.
Yes, you can go ahead
and you can send information
using HTTPS.
SSL will just send anything.
It's just a stream.
It's just a reimplementation
of TCP
that is almost accurate.
The problem is
99% of the CGI scripts
that do HTTP upload
are completely rootable.
They are.
They suck.
And that's because
somebody had to go ahead
and use a method
that wasn't conveniently made.
It wasn't conveniently
encapsulated for them.
SSH does convenient encapsulation
and that's why it works well.
So questions?
Comments?
Methods that you wish
actually existed
to get data from point A
to point B?
Hit me.
That would be
docspara.com.
Backwards paradox.
Go ahead.
It's not their fault.
It's not their fault.
If you connect to a machine
and it says the host key changed,
there are so many situations
where the host key
actually would have changed
that you just say,
yeah, okay, I don't care.
I don't care that this machine
can't prove it's who I think it is.
I'm just going to go in anyway
because at the end of the day,
my job is to actually
get into this server.
My job is not to scream and shout
about, you know, crypto.
What does everyone say?
They just say,
oh, I can't believe it.
This machine was broken.
You know, hey, admin,
you're stupid,
but I still went in anyway.
That could have been dangerous.
No, the actual,
I'm actually,
a solution is being worked on.
There's a system called SRP out there,
secure remote passwords.
It does mutual authentication
using passwords.
So if the server actually
doesn't know my password,
SRP doesn't even make it
need to know password.
SRP lets it know just
a cryptographic hash
of that password.
If the server doesn't have
any information about me,
then I won't be able to
successfully log into it.
So I get some aspect of
something I can remember
in my head as opposed to
some long fingerprint string,
but something I can remember
in my head,
if the server does not know that
or does not know anything about it,
I won't be able to log into it.
Now, if you use that method
to authenticate a change
in host keys,
you eliminate 99%
of the information
of the issues where
someone will just automatically
replace a host key.
It's like, yeah,
you're connecting to some machine,
and not only does it have
the wrong cryptographic information,
it doesn't know your password.
Yeah, I'm going away now.
Go ahead.
.
Go to FreshMeet,
search for SCP only.
Replace your user shell
with SCP only.
All that will be
able to do is execute
the SCP command.
Secure ID has specific support
for it in a unsupported patch.
It's in the contract directory.
Go ahead and compile it.
It may even be a configure option.
Generic functionality is being added
to make it easier
to do stuff like secure ID,
to do stuff like crypto card
and whatnot.
So that's been a big issue
a lot of places
with custom authentication methods,
so that should be up and running soon.
But secure ID is specifically supported.
Go ahead, right there.
.
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successfully. It's a basic precept of security.
Pseudo limits the
damage that somebody can do, but the bottom line
is you have a pseudo command that only
an admin can execute.
You want there to be a difference between
your user account and your admin account.
If you give your user account
extra features, then
what's the difference about having...
Basically, you need there to be
that separation between user and root.
If it's not there, a lot of
Unix permission stuff breaks.
You can't get around that. What was your other
question?
What's a good replacement
for Rdisc
for encrypted, secure transmission
of new files, say, on a
contact every night, or one
Unix box to another over the
internet without it being
Rdisc over SSH?
Yeah, Rdisc over
SSH. Or Rsync,
excuse me.
The only problem I was learning about with that is for it to be
automated, you've got to have that other server storing
the password.
If the first box is attacked,
you've got straight access.
Use restricted shells
like the SCP-only shell
and distribute
host keys.
Email me
about this later. We'll see
if we can come up with a generic solution to it.
Go ahead.
Can you say a word on cryptographic
hardware accelerators?
Fast.
Cryptographic
hardware accelerators, I believe, actually
will work with OpenSSH because
it gets most of its crypto out of OpenSSL.
I haven't verified that.
In general, though, CPUs are getting pretty fast.
The OpenBSD team just got, what was it,
a 2.5 megabit per second triple-desk,
using 1% of a mid-grade Pentium III.
So, you know, you extrapolate that out,
you get about 250 megabit.
Perfect? No.
Fast? Faster than you're probably going to need for
anything but a full wireline crypto?
Yeah, that'll work.
Oh, incidentally, you have all these VPN vendors bragging,
yeah, we've got something that you can terminate
60,000 connections against.
Great.
So you have one machine that if I break that machine,
it has decrypted information for 60,000 hosts.
Great.
The nice thing about my solution is, yes,
you have pathways to 60,000 other hosts, but you don't have
any of the data that went through it and you don't have
any of the authentication methods through it.
Go ahead.
I was just wondering about how there were no solutions for,
if you got into a box, you know, the key was there in the box.
These little cable motor boxes are not like that.
What we've done is taken the chip, the center layer,
the chip, the key, the only way to actually read or write from
that center layer is through fuses on the side to get blown
at the factory.
There's no way to get to the key or to the output.
This is the hardware dream.
This is the dream that if you put the key really, really,
really deep into your hardware, nobody will ever get access to it.
And I think the perfect rebuttal is anything that has anything
to do with DirecTV?
Anything?
Not DirecTV.
The bottom line, okay, the bottom line is, yes,
storing something very deep in hardware can be useful,
but in the end, that keying material needs to be accessible
to the outside world or else what's it matter?
Great.
You have a key.
You have bits that can't be accessed.
And by circumventing the method by which the legitimate bits are read off
or the legitimate bits are worked through, by circumventing that
and using it in a context that a company didn't expect,
you often can receive the same utility.
Anyone else?
Back there in the white.
What sort of implementation would you recommend for uploading files
to a web service yearly?
I really should have gone into this during this talk.
There's a wonderful app out there called MindTerm.
It is a full SSH implementation written in Java.
Somebody has gone ahead and added SCP support to MindTerm.
So it'll go ahead and actually gives you a decent interface over SSH to throw up files.
User goes to a web page, it loads a Java app.
The security of the Java app is actually verified by the, you know,
by code signing.
And you use that to go ahead and upload your files.
That's worked pretty well.
What?
IsNetworks.
IsNetworks.
Go ahead.
Yeah, you mentioned the following all along.
What do you think about using Kerberos for network authentication?
Kerb's one of those things that I know.
I know deep inside it's good.
I know deep inside it.
It's not secure.
But just the whole concept of one machine that if it's penetrated, everything dies just
really seems to bleed single point of failure to me.
So I have issues with it personally.
Other people use it very successfully.
Other people use it in very large scale deployments.
So SSH has quite a bit of code in it to make that feasible.
Personally, I have issues with some of that Kerb's philosophy.
But SSH itself.
SSH itself does support what you're referring to.
Go ahead.
I think you've expressed the point that no one actually should be SSH1 or SSH2.
Nobody should.
But okay.
Would you rather do SSH1 or would you rather do Telnet?
Well, I'd rather do SSH1 too.
One little political statement, SSH.com, why guys?
Why did you bungle the SSH1 to SSH2?
Why did you do SSH2 to SSH2 migration?
If you ever do anything to do with migration, please for the love of God be backwards compatible
and be upwards compatible if possible.
What basically happened was this.
SSH.com comes out with SSH2, a complete reimplementation with no new features.
Good job guys.
The entire SSH2 protocol was implemented in the SSH1 framework.
You can't do that unless you have no new features.
It physically doesn't.
Because code doesn't happen.
But they basically set it up so if you upgraded your servers to SSH2, suddenly all your SSH1
clients started screaming at you.
If you upgraded your SSH1 clients to SSH2, suddenly you couldn't connect anywhere.
So you had this catch-22 situation and what ended up happening is nobody ended up upgrading
to SSH2.
Open SSH comes out, does nice convenient migration path from SSH1 to SSH2 by simply supporting
both.
Well, it's not the freeness.
The freeness of Open SSH is nice.
But the reason Open SSH was migrated to over the SSH2 server was because it didn't break
everything.
Go ahead.
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Yeah, the Cisco
routers don't support SSH2.
It's amazing
they support SSH1 at all.
They barely got
that going.
But yeah, the reason why there
is concern about the SSH1 protocol is
because there are these issues
in it that do look like sooner
or later are going to lead to compromise.
There's
no out-of-the-box
penetration of an existing stream.
The best you can do, there's been some
interesting work determining
someone's password by the amount of time it takes
between packets when they hit
the keys.
Ettercap, what's it do?
I mean, I know it's another sniffer,
but does it have a special SSH mode to it?
It sounds...
It sounds...
It sounds like it's doing the...
It sounds like what you're saying is that it's doing
the host key spoofing
and waiting for the user to just say, I don't care,
I want to get into this host, even though the host keys
don't match. SSH2 is going to
be vulnerable to that, too.
In fact, about the only really good solution
to that is to have SRP support
and to use the password to authenticate
a change in host keys.
Well, I mean, seriously,
if, I mean, SSH1 or SSH2,
if your host key doesn't match and you accepted
anyway, you're screwed.
Hmm.
I'll check it out. Send me an email
about it as well.
Anyone else?
Well, in that case,
it's been a blast.
Thank you.
